58同城商业生态与智能发展中心反作弊测试平台建设
导读
对于反作弊紧急上线且直接影响在线收入的需求,要求测试高效且质量高,所以我们对业务和系统的分析的理解，引入测试平台的思路搭建了反作弊测试平台，本文主要介绍了58同城商业生态与智能发展中心反作弊测试平台的建设。
背景
当前移动时代，流量快速变现的利益驱动下，流量造假时有发生，作弊流量使广告主为作弊流量付费，损失了广告主的利益；同时商业广告系统需要为处理造假流量消耗一定的资源，极端情况下甚至会影响商业广告系统的稳定性及在线生产能力；但是反作弊过分严格，商业广告系统本身收益也会受到损失，因此各大商业广告系统中会研发各种反作弊技术合理地过滤作弊流量。
反作弊业务简介
业务特点
反作弊业务主要负责过滤虚假流量；
首先，需要通过算法及用户行为分析等方法识别出作弊特征；
然后，对每一条流量进行特征提取，将提取后的特征与已知的作弊特征进行匹配；
如果该流量的特征匹配作弊特征，会被认定为作弊流量。原理见示意图：
需求特点
反作弊业务需求具备的特点：
规则类：反作弊业务主要针对潜在的作弊特征挖掘和识别，形成规则，因此项目需求都以新增、修改规则，删除规则为导向；
前置数据依赖性大：从业务角度，因为判定作弊流量的数据源大部分都来自外部服务以及反作弊本身离线挖掘的信息（即黑名单)；从测试角度，想要每条用例有预期结果，就需要把依 赖的数据事先配置正确;
纯接口测试：反作弊服务采用纯接口测试；
迭代频繁：反作弊是收入的直接影响，需求都是临时加急，迭代快速；
需求分类
新增规则配置类：平台能力已支持，这类需求只需要在规则配置添加配置；
新增规则逻辑类：平台能力不支持新增规则， 该类需求需要研发平台能力， 再新增规则配置；
变更规则逻辑类：平台能力已支持规则的实现逻辑，因业务需求的变化， 需要调整规则的实现逻辑；
变更接口协议：服务接口对外协议发生变更的需求；
平台能力变更: 平台底层实现变更的需求；
测试方案
其实针对反作弊业务的测试，核心在于保证各种规则的测试场景全面性和正确性；通过对日常需求的梳理，我们将其分为5类(如下图），
新增规则配置类是基于已支持的平台能力上，通过配置合理的参数来实现业务逻辑，故这类需求只需要校验配置，无须对服务进行测试；
测试痛点
先给大家看一下目前测试阶段执行用例的思路图：
每一类规则都有一套固定模版，因此在设计每个需求的测试用例时，我们都要人为依据模板构造请求；
需要将前置数据依赖大的规则对应的用例所依赖的数据人为配置正确；
人为校验结果和日志，重复性较高，而且效率低；
由于反作弊需求本身迭代频率高且紧急，所以我们在保证测试质量的同时，还要做到快速测试上线；
所以，测试痛点可以总结为以下两点：（1）人工构造请求、数据准备和清理，人工日志校验，重复性高，效率低；（2）临时紧急；
从测试痛点出发，我们打破了常规测试思路，研发了一套反作弊自动化测试框架——反作弊测试平台;
反作弊测试平台
1.平台简介
反作弊测试平台目标可以分为业务目标和平台目标2方面；
业务目标
(1)保存请求和前置数据，自动进行前置操作和清理，取代手动操作，来解决人工进行数据准备和清理，人工日志校验, 效率低下问题；
(2)根据服务的规则配置自动生成用例, 解决人工构造请求问题；
(3)QA根据RD自测形成的测试报告对测试场景进行查漏补缺，避免相同case重复测试，可缩短测试时间；
(4)一键回归，并披露回归测试报告；
(5)记录RD和QA一次需求的操作数据，解决测试完成并出现线上问题后，回溯是否存在因测试操作不当或操作错误的测试数据而引发的问题；
平台目标
(1) 用户：界面化，操作简单，并提供用户使用文档；
(2) 开发者：使用易用的设计模式，易于扩展，以支持快速开发；提供开发者文档；
(3) 平台：支持测试用例参数界面化配置、可视化执行结果；
总结上述2方面，我们在测试思路上进行了转化，将之前人为校验规则、用例编写、执行用例，出具测试报告全部由平台完成。
2.架构简介
上图是平台架构图， 现在我将从用户管理、规则规则、规则配置文件校验、用例管理、测试报告进行介绍；
1、用户管理
基于反作弊信息保密性，反作弊服务及测试数据都只对相关人员开放，因此测试平台需要对用户的状态和权限进行管理，
管理员授权的用户并在使用中的状态才能使用该系统；
用户的状态分为使用中和已删除；
使用中状态的用户能通过验证登录该平台，已删除的用户无法登录该平台；
管理员添加用户，设置用户状态为使用中；
管理员删除用户，设置用户状态为已删除；已删除的用户重新添加，将该用户的状态由已删除改为使用中；
用户权限有QA、RD 和管理员，根据不同权限的用户开放不同的功能；
管理员授予QA权限或RD权限给状态为使用中的用户；未授予权限的用户，默认是RD权限；
QA权限高于RD权限，只有QA权限的用户才有数据删除的权限。
2、规则管理
主要负责对有权限的用户实现对规则的增删查；此外，前端页面向用户披露平台如下数据是依赖规则的状态来实现的；
已支持的规则：统计状态为使用中的规则；已支持待录入用例的规则：统计状态为待录入用例的规则；已录入不能支持的规则：统计规则状态为不支持的规则；
1)规则添加：规则配置并解析配置来添加规则；
2)规则查询：查询条件包括服务名、规则类型、产品等；
3)规则删除：只有QA权限才能删除规则， 规则删除进行逻辑删除，设置规则的状态为已删除， 并不是真实的从数据库中删除数据；删除动作支持记录删除人和删除时间。
3、规则配置文件校验
规则校验解决的问题：
从业务角度看，规则配置的正确性表达了业务场景的正确性，所以在生产环境里，必须保证其正确；
从测试平台角度看，自动生成用例依赖规则配置的正确性；保证配置正确可避免因开发提交错误的配置文件而生成不合理的用例；
基于以上2个角度，需要对规则配置的正确性进行校验；
实现原理：
在线从igit上拉取的测试版本和线上版本规则配置文件，对比测试版本在线上版本的基础上的变更，
将变更点提供给用户来确认变更；经用户确认变更后，将变更后的规则信息存储；
如果平台已支持该规则能够自动生成用例，修改后会将该规则原有用例的状态设置为已删除，再重新生成新用例，新用例和规则的状态都设置为使用中；
如果平台尚未支持该规则自动生成用例，修改后，设置规则的状态为待录入用例状态，并将该规则原有用例的状态设置为已删除，并提示用户用例需要重新录入，原有用例不可用；
4、用例管理
平台支持的自动化回归需要依赖存量用例及其依赖数据，平台提供给用户对用例的增删改查功能，还提供用例自动生成功能来解决用例编写
耗时久的问题；接下来将从用例添加、修改、查询、删除方面进行讲述；
(1）用例添加
1) 用例手动录入
对于部分目前尚不支持自动生成用例的规则，需要手动录入用例；
录入用例描述、请求、前置数据、期望结果，然后将其存入用例库中，用例的状态设置为使用中；
2) 用例自动生成
由于我们变更接口协议需求和平台能力变更需求很少， 需求都集中在 规则配置类、新增规则逻辑类、变更规则逻辑类；
这三类需求需要基于规则的配置编写用例，当一次大需求上百个规则，编写用例耗费大量的精力和时间
为解决这个测试痛点，我们通过分析规则配置中的特征条件，推导出该规则的非作弊特征条件；然后从以下2部分生成用例：
I）正向用例：穷举出作弊特征条件，把特征条件的数据对应到用例描述、请求、前置数据和预期结果生成用例；
II）反向用例：穷举出非作弊特征条件，把特征条件的数据对应到用例描述、请求、前置数据和预期结果生成用例；
由正向用例的特征条件推导反向用例特征条件，
举例：假设platform 值域为[A,B,C],platform=A或B 是作弊特征条件，可推导出platform=C是非作弊特征条件， 那么platform=C的流量则不能被过滤；
可根据以上思想自动生成用例；如下图
实现原理：（非作弊特征条件同理）
i.穷举条件：解析规则特征，穷举出作弊特征条件；
ii.遍历条件：一个条件代表满足作弊特征的一条用例；每一个条件有可能包括一个或多个字段及其字段值;
iii.处理条件：
a)获取请求模板，将条件中各字段及其字段值更新到模板中，构造成用例请求;
b)以K=V格式拼接条件中各字段及其字段值成一个字符串，作为用例描述；
c)利用前置处理器依据条件信息来生成前置数据；前置数据构造主要为以下三类
黑名单数据构造：负责将条件信息中用于表示黑名单数据标识用请求中真实的数据进行拼装，比如 黑名单：userID_广告ID，值：1，方法：set;请求中userID=10，广告ID=2，该构造器则生成{"blackdata": [{"key":"10_2","value"：1,"method":"set"}]},该数据在用例执行时, 黑名单处理器会对该条数据进行处理；
Mock数据构造：负责指定需要构造服务和返回结果；如: {"Mockdata": [{"service":"A","returndata"：1}]}；
参数定制化构造：负责指定将当前规则中不关联且需要变化的字段，如： {"Changedata": [{"keys":"A,B"}]}；
d)预期结果为作弊特征的规则码，非作弊特征的预期结果是不满足作弊特征时服务返回的默认结果;
iv.用例入库：生成的正向用和反向用例都保存到用例库；
2)用例查询：查询条件包括服务名、规则类型、产品、规则4种组合查询；
3)用例修改: 负责对用例的描述、请求、期望结果、前置数据进行单项修改并保存，并记录修改人和修改时间
4)用例删除：只有QA权限才能删除用例，用例删除进行逻辑删除，只是设置用例的状态为已删除，并不是真实的从数据库种删除数据；删除动作支持记录删除人和删除时间
5、全量用例回归和用例执行接口
回归接口负责对存量用例进行回归，支持以下回归的粒度：
按照服务维度进行用例回归，针对被改动服务的用例进行全量回归；
按照计费类型进行用例回归，类型有cpc类、cpt类、cpa类等；
按照指定的规则批量进行回归；
执行接口负责执行单条用例；
回归接口和执行接口底层基于执行引擎来执行用例，这三者的关系如下图:
6、执行引擎
执行引擎将用例执行阶段分为前置处理、接口调用、校验和数据清理，一共四层，按照顺序依次进行处理，并设计了回滚机制；
下面将分别对执行引擎的模块进行讲述；
（1）前置处理器：负责对用例进行预处理，通过对我们的服务分析，目前需要以下几类数据进行前置处理，包括对用例的请求进行定制化处理、前置数据入库；（2）mock数据处理；未来有新的数据处理器，支持可扩展；
黑名单处理器：负责将该用例构造的黑名单数据提前写入测试库；
Mock处理器：负责MOCK该用例场景下需要MOCK的外部服务返回结果；
参数定制化处理器：负责处理该用例场景需要定制化的参数; 将请求重新赋值为根据参数类型生成的随机数据；如字符串参数每次随机生成字符串，整型参数每次随机生成整型数据。
（3）接口适配层：根据用例归属的服务来适配其接口进行调用；
(4）校验和统计：用例调用反作弊服务返回结果后，进行结果校验并分类出具测试报告；
（5）数据清理层：对前置数据的清理。目前能支持前置数据的删除、mock数据删除等；
执行引擎采用回滚机制设计
回滚机制解决的问题：隔离每一条用例的执行环境和数据，当一条用例执行校验只认定2种状态：通过或不通过；在任意一个环节失败，都回滚该环节之前的操作来保证下一条用例执行环境和数据不受影响；
实现原理：
将前置处理、接口调用、校验、数据清理中的操作分别拆分成独立的单元，例如前置处理环节拆分出MOCK外部数据单元、黑名单数据单元等多个数据处理单元；
每个单元实现接口：
do接口：负责处理单元逻辑；
undo接口：负责对单元中有前置的数据进行清理；
所有单元按照流程中规定的顺序执行逻辑，如果其中某个单元的do接口发生异常，就触发已完成处理do接口的所有单元执行其undo接口；
回滚时，按照倒叙处理单元的undo接口，进行数据清理，当所有的单元执行完成undo接口，数据清理就都完成了，该用例就执行失败；接下来就执行下一条用例。
平台回滚失败处理：重试3次，3次都失败时，记录失败的用例信息， 异常信息，其中异常信息包含失败的数据；可用于定位问题
7、测试报告
测试报告作为上线标准的依据，当总体测试报告测试通过率为100%，才能上线。
注：总体报告中，验证通过率=通过验证的规则数/总规则数；详细报告中，验证通过率=该规则通过验证的用例数/该规则用例数。
3、效果
QA 人力成本由天/人缩短1小时内/人；
后续规划
自动引入代码依赖包，进一步提升测试效率；
全部自动生成用例；
支持依赖类场景。
刘灵凤：高级测试工程师，2018年7月加入58同城，负责商业反作弊测试工作。